MacTech 1 to 12/MacTech-vol-1-12.toast/Reference/the cmsp digests ('94-'97)/csmp digest Vol 3 No 093

Text File | 1995-04-15 | 90KB | 2,449 lines

C.S.M.P. Digest             Sat, 15 Apr 95       Volume 3 : Issue 93

Today's Topics:

        Counting PICT resources in a particular file?
        Creating C++ objects inside handles
        Getting a printer's bit depth
        Good Mac software Installer
        InitZone strangeness
        Postponing AE reply ?
        Simple Sound
        TETextBox - How many lines ?
        [Q] Going modal-less?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Bryan Horling)
Subject: Counting PICT resources in a particular file?
Date: 30 Mar 1995 04:23:58 GMT
Organization: Trinity College

Does anyone know how to count the number of PICT resources (or any
resource type, for that matter) in a particular file?  This is to make a
pop-up menu of all their names on the fly in a preferences dialog box.  I
know about CountResources, but that seems like it'll look through the
whole resource list, thus getting additional ones from other places such
as the System.  Am I wrong about this?  Thanks in advance.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
       --Bryan Horling--       |  >>[e-mail]<<
       -Head Consultant-       |          Trinity College
  "Do not use GAK on varnished |          300 Summit St
    on unvarnished surfaces"   |          Hartford, CT
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                http://shakti.trincoll.edu/~bhorling

+++++++++++++++++++++++++++

>From [e-mail] (F. Degott)
Date: 30 Mar 1995 07:36:18 GMT
Organization: LMC-IMAG Grenoble France

In article <[e-mail]>,
[e-mail] (Bryan Horling) wrote:

> Does anyone know how to count the number of PICT resources (or any
> resource type, for that matter) in a particular file?  This is to make a
> pop-up menu of all their names on the fly in a preferences dialog box.  I
> know about CountResources, but that seems like it'll look through the
> whole resource list, thus getting additional ones from other places such
> as the System.  Am I wrong about this?  Thanks in advance.

Hi,

Try to use the function Count1Resources, describe below.
It's up to you to set the current res. file with your particular file
before the call, and restore the old res. file after that...

FUNCTION Count1Resources (theType: ResType) : INTEGER;

    Count1Resources is the same as CountResources except that it returns
the total number of resources of the given type in the current resource
file ONLY.

Bye.
__________________________________________
F.R. Degott  ([e-mail])
Lab. LMC-IMAG - Univ. Joseph Fourier - Grenoble - France

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: Thu, 30 Mar 1995 11:53:18 -0600
Organization: OuterNet Connections, Inc.

In article <[e-mail]>,
[e-mail] (Bryan Horling) wrote:

< Does anyone know how to count the number of PICT resources (or any
< resource type, for that matter) in a particular file?  This is to make a
< pop-up menu of all their names on the fly in a preferences dialog box.  I
< know about CountResources, but that seems like it'll look through the
< whole resource list, thus getting additional ones from other places such
< as the System.  Am I wrong about this?  Thanks in advance.
<
<        --Bryan Horling--       |  >>[e-mail]<<

Try Count1Resources.

____________________________________________________________________
Brian  Stern  :-{)}                           [e-mail]
Toolbox commando and Menu bard.             Will FlushCache for Cash

+++++++++++++++++++++++++++

>From Gordon Graber <[e-mail]>
Date: 30 Mar 1995 18:58:36 GMT
Organization: Drake University

In article <[e-mail]> Bryan
Horling, [e-mail] writes:
>know about CountResources, but that seems like it'll look through the
>whole resource list, thus getting additional ones from other places such
>as the System.  Am I wrong about this?  Thanks in advance.

I don't have the exact commands off the top of my head but:
You will need to set the current resource file, there is res manager call
to do this.
Then you will use CountIndResources to count only resources of a
particular type in the current resource file.

You're right, if you don't set the current res file and then use the
CountIndRes ( the current res file is the last opened res file ), you
will get the number of all the resources (of the type you specify) in all
opened res forks....

Gordon Graber: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (JoeLaff)
Date: 31 Mar 1995 10:21:00 -0500
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]> Bryan
Horling, [e-mail] writes:
>know about CountResources, but that seems like it'll look through the
>whole resource list, thus getting additional ones from other places such
>as the System.  Am I wrong about this?  Thanks in advance.

You are correct CountResources always counts the resources in ALL open
resource files, REGARDLESS of which resource file is active.

You need to UseResFile the file you wish to count in, and then call
Count1Resources(). The calls that include "1" (e.g. Get1Resource) only act
on the current resfile.

Good Luck.
Joe <----
****  E N D    O F    L I N E  ****

---------------------------

>From [e-mail] (John A. Dunning)
Subject: Creating C++ objects inside handles
Date: Sat, 18 Mar 1995 21:34:37 GMT
Organization: Princeton University


I just realized I don't understand how to create a new instance
of a class inside a handle.  The new operator returns a pointer
to the newly allocated memory, but I'm assuming on a Mac that that's
a non-relocatable block on the heap.  What if I want the the new
object to reside in a relocatable block, i.e. a handle?  I'd like
the constructors and destructors to be called appropriately
when the handle is allocated or deallocated.

The only way I can think of doing this is creating the instance
on the stack or with new, then doing a BlockMove to stick it in
a handle.  This is pretty cumbersome, and the destructor gets
called for the stack object, not the copy in the handle.  Seems
like there should be a better way.  Is there?  Or am I
approaching the problem the wrong way?  How do others handle
(as it were) objects inside relocatable blocks?

If it makes any difference (although I don't think it would),
I'm using CodeWarrior.

Any help you can give would be appreciated.

Thanks,

John
--

______________________________________________________________________________
John Dunning                                    [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Dan Lakeland)
Date: 19 Mar 95 20:08:41 GMT
Organization: Iowa State University, Ames, Iowa

In <[e-mail]> [e-mail] (John A. Dunning) writes:


>I just realized I don't understand how to create a new instance
>of a class inside a handle.  The new operator returns a pointer
>to the newly allocated memory, but I'm assuming on a Mac that that's
>a non-relocatable block on the heap.  What if I want the the new
>object to reside in a relocatable block, i.e. a handle?  I'd like
>the constructors and destructors to be called appropriately
>when the handle is allocated or deallocated.

>The only way I can think of doing this is creating the instance
>on the stack or with new, then doing a BlockMove to stick it in
>a handle.  This is pretty cumbersome, and the destructor gets
>called for the stack object, not the copy in the handle.  Seems
>like there should be a better way.  Is there?  Or am I
>approaching the problem the wrong way?  How do others handle
>(as it were) objects inside relocatable blocks?

Well, the short answer is "You DON'T" the explanation has to do with the
"this" pointer and virtual tables and destructors and multiple
inheritance. I don't fully understand it but the gist is that every C++
object needs to maintain a pointer to itself and if it were in a handle,
that pointer would become invalid quickly.

now, you can have all your object's DATA in a handle.

struct MyObjStruct
{
  // your data items here
};


//class declaration
private:

  MyObjStruct **theData;
};

then in the constructor do

theData = (MyObjStruct**) NewHandle(sizeof(MyObjStruct));

voila you get relocatable storage for your data, and only the overhead
of the object is static.
--
Daniel Lakeland: Macintosh Hacker, Mathematics Major, NRA Member.
Macintosh Hacking, an art best learned w/ an axe...
The computer programmer's worst nightmare:
Unwittingly finding compiler bugs.

+++++++++++++++++++++++++++

>From [e-mail] (Jerome Jahnke)
Date: Mon, 20 Mar 1995 04:29:44 GMT
Organization: BSD -- Academic Computing

In article <[e-mail]>,
[e-mail] (John A. Dunning) wrote:

> I just realized I don't understand how to create a new instance
> of a class inside a handle.  The new operator returns a pointer
> to the newly allocated memory, but I'm assuming on a Mac that that's
> a non-relocatable block on the heap.  What if I want the the new
> object to reside in a relocatable block, i.e. a handle?  I'd like
> the constructors and destructors to be called appropriately
> when the handle is allocated or deallocated.

Ahhhhhhhhhhh you can't do that, the reason is kinda simple but it has to
do with  the this table, and how the compiler keeps track of things. The
only real way to store a lot of data in a structure that is an object is
to stuff all the data into a handle and lock and unlock it as you need.

If you REALLY need handle based objects you need to look at something like
ObjectPascal, or use an earlier version of Think C++. I don't think any of
the compilers today use handle based objects, which stole a bit from the
C++ language set, no virtual destructors, and no multiple inheritence.

Contrary to popular belief pointers are not devil spawn. They have uses.

Jer,

--
Jerome Jahnke
BSD Academic Computing
University of Chicago
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (ALTURA)
Date: 20 Mar 1995 00:14:58 -0500
Organization: America Online, Inc. (1-800-827-6364)

> I don't think any of
> the compilers today use handle based objects, which stole a bit from the
> C++ language set, no virtual destructors, and no multiple inheritence.
SymC++ has a "handle-based" class extension to their C++ compiler ala
HandleObject in MPW.

==========================
Jordan Zimmerman
[e-mail]
http://www.altura.com/jordanz/home.html
Who is John Galt?

+++++++++++++++++++++++++++

>From [e-mail] (Jerome Jahnke)
Date: Mon, 20 Mar 1995 16:26:25 GMT
Organization: BSD -- Academic Computing

In article <3kj30i$[e-mail]>, [e-mail] (ALTURA) wrote:

> > I don't think any of
> > the compilers today use handle based objects, which stole a bit from the
> > C++ language set, no virtual destructors, and no multiple inheritence.
> SymC++ has a "handle-based" class extension to their C++ compiler ala
> HandleObject in MPW.

I stand corrected. I have not used them in a while due to the extreme
limitations they place on my C++ work.

Jer,

--
Jerome Jahnke
BSD Academic Computing
University of Chicago
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (bob gulian)
Date: 20 Mar 1995 18:26:46 GMT
Organization: CRL Dialup Internet Access

In article <[e-mail]>,
[e-mail] (Jerome Jahnke) wrote:

> In article <3kj30i$[e-mail]>, [e-mail] (ALTURA) wrote:
>
> > > I don't think any of
> > > the compilers today use handle based objects, which stole a bit from the
> > > C++ language set, no virtual destructors, and no multiple inheritence.
> > SymC++ has a "handle-based" class extension to their C++ compiler ala
> > HandleObject in MPW.
>
> I stand corrected. I have not used them in a while due to the extreme
> limitations they place on my C++ work.
>
> Jer,
>
> --
> Jerome Jahnke
> BSD Academic Computing
> University of Chicago
> [e-mail]


Ok, here's how Lippman would do it.  I paraphrase and transmogrify.

class BaseClass {
public:
   void *operator new(size_t);
   void *operator delete();
   void Lock();
   void Unlock();
private:
   Handle mOurStore;
};


void *BaseClass::operator new(size_t size)
{
   mOurStore = NewHandle(size);
   return (BaseClass *)mOurStore;
}

void *BaseClass::operator delete()
{
   if (mOurStore)
      DisposHandle( mOurStore );
   mOurStore = NULL;

}

void BaseClass::Lock()
{
   HLock( mOurStore );
}

void BaseClass::Unlock()
{
   HUnlock( mOurStore );
}


Then you subclass all classes you want Handle Based from BaseClass.

Okay, now, having given you a way to do this, I have to say that it is
most foolhardy.  Handles are TROUBLE!  You absolutely must lock your class
everytime you pass a member of it in a function.  You better remember to
unlock it too.  In an asynchronous message passing OOP environment this is
bound to be dangerous and slow.

Overloading new and delete is not a bad idea.  Symantec's new and delete
leave something to be desired but call malloc() not NewHandle().  Anyway,
that's my two cents.

Bob,

+++++++++++++++++++++++++++

>From [e-mail] ([e-mail])
Date: 20 Mar 1995 22:17:17 -0500
Organization: Delphi Internet Services Corporation

[e-mail] (ALTURA) writes:

>> I don't think any of
>> the compilers today use handle based objects, which stole a bit from the
>> C++ language set, no virtual destructors, and no multiple inheritence.
>SymC++ has a "handle-based" class extension to their C++ compiler ala
>HandleObject in MPW.

As does Metrowerks.  Derive a class from HandleObject:

class HeyICanProgram : HandleObject
{
    // ....
};

________________.______.._____...___....._.....................
Chris Thomas, [e-mail], friend of the devil
"And how did someone screw this up?  Let's call up Symantec and scream
at them for a while."

+++++++++++++++++++++++++++

>From [e-mail] (Jens Alfke)
Date: Mon, 20 Mar 1995 21:19:05 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail]
(Dan Lakeland) wrote:

> Well, the short answer is "You DON'T" the explanation has to do with the
> "this" pointer and virtual tables and destructors and multiple
> inheritance. I don't fully understand it but the gist is that every C++
> object needs to maintain a pointer to itself and if it were in a handle,
> that pointer would become invalid quickly.

No, this is not true. There's nothing stopping you from storing an object
in a handle. Most Mac C++ compilers even make it easy for you by
predefining a base class called HandleObject; any class derived from
HandleObject allocates its instances in handles. The nice part is that you
can continue to use the normal '->' form to refer to methods and instance
variables; the compiler takes care of adding the additional dereference.
What is _not_ possible is to mix handle objects and multiple inheritance;
this is because MI relies on the fact that an object can contain another
object, but of course you cannot store one relocatable block inside
another. For the same reason, it's obviously impossible to use a
HandleObject itself (not just a pointer to one) as a member of another
object.

CFront, Symantec C++ and CodeWarrior all support HandleObject. And in
THINK C (which isn't really C++) all objects are allocated in handles.


Jens Alfke_________OpenDoc [e-mail]
                                           OpenDoc info: FTP to CILabs.org

         Visit Scenic Flood Control Dam No. 3.

+++++++++++++++++++++++++++

>From [e-mail] (James Rodden)
Date: Wed, 22 Mar 1995 01:34:32 -0800
Organization: DD/MF & Associates

In article <[e-mail]>,
[e-mail] (Jens Alfke) wrote:

>In article <[e-mail]>, [e-mail]
>(Dan Lakeland) wrote:
>
>> Well, the short answer is "You DON'T" the explanation has to do with the
>> "this" pointer and virtual tables and destructors and multiple
>> inheritance. I don't fully understand it but the gist is that every C++
>> object needs to maintain a pointer to itself and if it were in a handle,
>> that pointer would become invalid quickly.
>
>No, this is not true. There's nothing stopping you from storing an object
>in a handle. Most Mac C++ compilers even make it easy for you by
>predefining a base class called HandleObject; any class derived from
>HandleObject allocates its instances in handles. The nice part is that you
>can continue to use the normal '->' form to refer to methods and instance
>variables; the compiler takes care of adding the additional dereference.
>What is _not_ possible is to mix handle objects and multiple inheritance;
>this is because MI relies on the fact that an object can contain another
>object, but of course you cannot store one relocatable block inside
>another. For the same reason, it's obviously impossible to use a
>HandleObject itself (not just a pointer to one) as a member of another
>object.
>
>CFront, Symantec C++ and CodeWarrior all support HandleObject. And in
>THINK C (which isn't really C++) all objects are allocated in handles.
>

Really?! Where is this class found in the CodeWarrior directories?

Jim

--
J.Rodden, DD/MF & Associates
Simlab Development Team, Product Architect

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Thu, 23 Mar 1995 16:43:30 +1200 (NZDT)
Organization: (none)

[e-mail] (John A. Dunning) writes:
> I just realized I don't understand how to create a new instance
> of a class inside a handle.  The new operator returns a pointer
> to the newly allocated memory, but I'm assuming on a Mac that that's
> a non-relocatable block on the heap.  What if I want the the new
> object to reside in a relocatable block, i.e. a handle?

Do *not* do this!

C++ objects can *not* live in moveable memory.  Apple privided special
support in the CFront compiler for doing this, but now that CFront is
not supported any more you have no way of doing this.

It's possible to get away with it (apart from the constructor/destructor
problems) with single-inheritence hierachies, but if you use multiple
inheritence anywhere then handles are *death*.  This is because C++
will be creating and passing around pointers into the middle of the
object, and you have no way of knowing if the object moves.

Now the question is: *why* do you want to put a C++ object into a handle?
I can't see a good reason to do it.

It make a lot of sense to have a small C++ object that *contains* a
Handle to some storage, and manages it for you in some way, automatically
freeing the handle when the C++ object's destructor is executed.  And
it's often useful to have several such small C++ objects share one
Handle, maintaining a "reference count" to say how many are using it and
freeing the Handle when the last reference goes.

But this is quite different to what you are asking about.

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (John A. Dunning)
Date: Mon, 20 Mar 1995 08:26:00 GMT
Organization: Princeton University

In article <[e-mail]>,
Dan Lakeland <[e-mail]> wrote:
>In <[e-mail]> [e-mail] (John A. Dunning) writes:
>
>>I just realized I don't understand how to create a new instance
>>of a class inside a handle.  The new operator returns a pointer
>>to the newly allocated memory, but I'm assuming on a Mac that that's
>>a non-relocatable block on the heap.  What if I want the the new
>>object to reside in a relocatable block, i.e. a handle?  I'd like
>>the constructors and destructors to be called appropriately
>>when the handle is allocated or deallocated.
>
>Well, the short answer is "You DON'T" the explanation has to do with the
>"this" pointer and virtual tables and destructors and multiple
>inheritance. I don't fully understand it but the gist is that every C++
>object needs to maintain a pointer to itself and if it were in a handle,
>that pointer would become invalid quickly.

Then how do classes like LDynamicArray work?  It stores the
items of the array in a handle, the size of which it adjusts
as items are added and deleted.  To insert an item, you pass
a pointer to it, and the data is copied into the handle through
a BlockMove.

Does this mean you shouldn't insert class objects into an
LDynamicArray?  I've used an LNTable before (which uses an LDA
to store its data) with objects I created with new.  I inserted
the item into the table, then deleted it.  That seemed to work
okay.  Maybe I just got lucky.

And where do objects allocated with new reside?  Do they just
get stuck in the middle of the heap?  Or does the Memory Manager
try to do something intelligent with them?  What if you need
to build a tree of nodes?  It seems like your heap will get
fragmented pretty fast if you add and delete a lot of the nodes.

John
--

______________________________________________________________________________
John Dunning                                    [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: Thu, 23 Mar 1995 09:26:50 -0600
Organization: OuterNet Connections, Inc.

In article <[e-mail]>,
[e-mail] (John A. Dunning) wrote:

< In article <[e-mail]>,
< Dan Lakeland <[e-mail]> wrote:
< >In <[e-mail]>
[e-mail] (John A. Dunning) writes:
< >
< >>I just realized I don't understand how to create a new instance
< >>of a class inside a handle.  The new operator returns a pointer
< >>to the newly allocated memory, but I'm assuming on a Mac that that's
< >>a non-relocatable block on the heap.  What if I want the the new
< >>object to reside in a relocatable block, i.e. a handle?  I'd like
< >>the constructors and destructors to be called appropriately
< >>when the handle is allocated or deallocated.
< >
< >Well, the short answer is "You DON'T" the explanation has to do with the
< >"this" pointer and virtual tables and destructors and multiple
< >inheritance. I don't fully understand it but the gist is that every C++
< >object needs to maintain a pointer to itself and if it were in a handle,
< >that pointer would become invalid quickly.
<
< Then how do classes like LDynamicArray work?  It stores the
< items of the array in a handle, the size of which it adjusts
< as items are added and deleted.  To insert an item, you pass
< a pointer to it, and the data is copied into the handle through
< a BlockMove.

LDynamicArray has a handle as a data member.  That's no problem.  The
object itself doesn't move, only its data.

<
< Does this mean you shouldn't insert class objects into an
< LDynamicArray?  I've used an LNTable before (which uses an LDA
< to store its data) with objects I created with new.  I inserted
< the item into the table, then deleted it.  That seemed to work
< okay.  Maybe I just got lucky.

You can insert object pointers into an LDynamicArray, not the objects
themselves.  It's perfectly OK, and a common idiom to make lists of object
pointers. That's not the same as making lists of objects.

<
< And where do objects allocated with new reside?  Do they just
< get stuck in the middle of the heap?  Or does the Memory Manager
< try to do something intelligent with them?  What if you need
< to build a tree of nodes?  It seems like your heap will get
< fragmented pretty fast if you add and delete a lot of the nodes.

Yes, heap fragmentation is a potential problem of using pointer-based
objects.  Operator new runs on top of the memory manager, allocating large
blocks (say 32K) from the heap that it then parcels out when you call new
and reclaims when you call delete.  If you have special needs then you can
override operator new for one or more classes and do it a smarter way.

I used the handle-based objects in TCL 1.1.3.  They worked fine but were
limited.  (We didn't have real C++ at that time anyway so it wasn't a
problem.)  These objects would sometimes move at inopportune times if you
weren't careful, so having pointer-based objects makes life easier.  I
would recommend not worrying about this.  If you profile your app and
inspect its memory and find out that the heap is grossly fragmented then
think about overriding operator new.

<
< John
< --
<
< ______________________________________________________________________________
< John Dunning                                    [e-mail]

____________________________________________________________________
Brian  Stern  :-{)}                           [e-mail]
Toolbox commando and Menu bard.             Will FlushCache for Cash

+++++++++++++++++++++++++++

>From [e-mail] (Jens Alfke)
Date: Thu, 23 Mar 1995 18:01:43 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (John A. Dunning) wrote:

> Then how do classes like LDynamicArray work?  It stores the
> items of the array in a handle, the size of which it adjusts
> as items are added and deleted.  To insert an item, you pass
> a pointer to it, and the data is copied into the handle through
> a BlockMove.
> Does this mean you shouldn't insert class objects into an
> LDynamicArray?

Go ahead, it's fine. The only problem would be if a method of one of these
objects called a routine that could move memory, and the handle moved.
This would invalidate the 'this' parameter to the method. This is the same
problem that's been with us since 1984. Just lock the handle first or copy
the object to someplace that can't move.


Jens Alfke_________OpenDoc [e-mail]
                                           OpenDoc info: FTP to CILabs.org

         Visit Scenic Flood Control Dam No. 3.

+++++++++++++++++++++++++++

>From [e-mail] (Thomas P. Condon)
Date: 23 Mar 1995 17:58:45 GMT
Organization: Condon Consulting Services, Inc.

I don't think Jens Alfke understood what was being asked.

The simple answer of why not to do this is that a call to a member
function always passes an implicit "this" on the stack.  You can get into
the situation that

1.) You call myHandleObject->fInnerObject->DoSomething();

2.) The compiler pushes the address to fInnerObject just before it calls
TInnerObject::DoSomething(). (Hey! This address points to the middle of a
relocatable block!!  DANGER!!!!)

3.) Call TInnerObject::DoSomething(). OOPs!  The routine
TInnerObject::DoSomething() is not in memory!  The segment loader goes to
work!  Loads the segment! Moves memory! Moves myHandle! Address pushed on
the stack is garbage now!!!

4.) KABOOM!





In article <[e-mail]>,
[e-mail] (Jens Alfke) wrote:

> In article <[e-mail]>, [e-mail]
> (Dan Lakeland) wrote:
>
> > Well, the short answer is "You DON'T" the explanation has to do with the
> > "this" pointer and virtual tables and destructors and multiple
> > inheritance. I don't fully understand it but the gist is that every C++
> > object needs to maintain a pointer to itself and if it were in a handle,
> > that pointer would become invalid quickly.
>
> No, this is not true. There's nothing stopping you from storing an object
> in a handle. Most Mac C++ compilers even make it easy for you by
> predefining a base class called HandleObject; any class derived from
> HandleObject allocates its instances in handles. The nice part is that you
> can continue to use the normal '->' form to refer to methods and instance
> variables; the compiler takes care of adding the additional dereference.
> What is _not_ possible is to mix handle objects and multiple inheritance;
> this is because MI relies on the fact that an object can contain another
> object, but of course you cannot store one relocatable block inside
> another. For the same reason, it's obviously impossible to use a
> HandleObject itself (not just a pointer to one) as a member of another
> object.
>
> CFront, Symantec C++ and CodeWarrior all support HandleObject. And in
> THINK C (which isn't really C++) all objects are allocated in handles.
>
>
> Jens Alfke_________OpenDoc [e-mail]
>                                            OpenDoc info: FTP to CILabs.org
>
>          Visit Scenic Flood Control Dam No. 3.

+++++++++++++++++++++++++++

>From [e-mail] (Ivan M CaveroBelaunde)
Date: Thu, 23 Mar 1995 20:25:36 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Thomas P. Condon) writes:

>I don't think Jens Alfke understood what was being asked.

>The simple answer of why not to do this is that a call to a member
>function always passes an implicit "this" on the stack.  You can get into
>the situation that

>1.) You call myHandleObject->fInnerObject->DoSomething();

>2.) The compiler pushes the address to fInnerObject just before it calls
>TInnerObject::DoSomething(). (Hey! This address points to the middle of a
>relocatable block!!  DANGER!!!!)

>3.) Call TInnerObject::DoSomething(). OOPs!  The routine
>TInnerObject::DoSomething() is not in memory!  The segment loader goes to
>work!  Loads the segment! Moves memory! Moves myHandle! Address pushed on
>the stack is garbage now!!!

>4.) KABOOM!

I don't think you understood what Jens said, actually, or how MI and
embedded objects work in current C++ implementations. First, statement 1
implies that fInnerObjects is not declared as a CSomeObject, but as a
CSomeObject* (you call its DoSomething method via the -> operator instead
of the . operator). Thus, when "this" is passed to DoSomething, it will
*not* pass a pointer to the middle of a handle (since the actual contents
of fInnerObject are not inside myHandleObject) and nothing bad will happen.
Jens obliquely refers to this

>> For the same reason, it's obviously impossible to use a
>> HandleObject itself (not just a pointer to one) as a member of another
>> object.

It's actually not quite that: it's impossible to use any kind of object
as a member of a HandleObject (note that this restriction does not
apply to pointer to objects, however). Thus both

class TMixedObject : TMixin1, TMixin2 {
        /* This is a subclass of HandleObject */
...
  virtual void DoSomething1(); // inherited from TMixin1
  virtual void DoSomething2(); // inherited from TMixin2
}

and

class THandleObject {
        /* This is a subclass of HandleObject */
...
  TSomeOtherObject fObject; // contains DoSomething() method
};

are evil. In the first case, either DoSomething1 or DoSomething2
(depending on the implementation) will get a "this" that points to
the middle of the handle (the case you describe). In the second case,
DoSomething() will get a "this" that points to the middle of the
handle as well. If the second case, however, had been declared as:

  TSomeOtherObject *fObject;

that would've worked.

-Ivan
- --
Ivan Cavero Belaunde ([e-mail], [e-mail])
Avid VideoShop Lead
Avid Technology, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Jerome Jahnke)
Date: Fri, 24 Mar 1995 00:49:15 GMT
Organization: BSD -- Academic Computing

In article <[e-mail]>,
[e-mail] (John A. Dunning) wrote:

> In article <[e-mail]>,
> Dan Lakeland <[e-mail]> wrote:
> >In <[e-mail]>
[e-mail] (John A. Dunning) writes:
> >
> >>I just realized I don't understand how to create a new instance
> >>of a class inside a handle.  The new operator returns a pointer
> >>to the newly allocated memory, but I'm assuming on a Mac that that's
> >>a non-relocatable block on the heap.  What if I want the the new
> >>object to reside in a relocatable block, i.e. a handle?  I'd like
> >>the constructors and destructors to be called appropriately
> >>when the handle is allocated or deallocated.
> >
> >Well, the short answer is "You DON'T" the explanation has to do with the
> >"this" pointer and virtual tables and destructors and multiple
> >inheritance. I don't fully understand it but the gist is that every C++
> >object needs to maintain a pointer to itself and if it were in a handle,
> >that pointer would become invalid quickly.
>
> Then how do classes like LDynamicArray work?  It stores the
> items of the array in a handle, the size of which it adjusts
> as items are added and deleted.  To insert an item, you pass
> a pointer to it, and the data is copied into the handle through
> a BlockMove.

Because the class LDynamic Array is NOT a handle, it is a pointer. There
is member field of that class that IS a handle. A very big difference.

Jer,

--
Jerome Jahnke
BSD Academic Computing
University of Chicago
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Mark Anderson)
Date: Fri, 24 Mar 1995 09:28:49 GMT
Organization: metrowerks

In article <[e-mail]>,
[e-mail] (James Rodden) wrote:

> In article <[e-mail]>,
> [e-mail] (Jens Alfke) wrote:
>
> >In article <[e-mail]>, [e-mail]
> >(Dan Lakeland) wrote:
> >
> >> Well, the short answer is "You DON'T" the explanation has to do with the
> >> "this" pointer and virtual tables and destructors and multiple
> >> inheritance. I don't fully understand it but the gist is that every C++
> >> object needs to maintain a pointer to itself and if it were in a handle,
> >> that pointer would become invalid quickly.
> >
> >No, this is not true. There's nothing stopping you from storing an object
> >in a handle. Most Mac C++ compilers even make it easy for you by
> >predefining a base class called HandleObject; any class derived from
> >HandleObject allocates its instances in handles. The nice part is that you
> >can continue to use the normal '->' form to refer to methods and instance
> >variables; the compiler takes care of adding the additional dereference.
> >What is _not_ possible is to mix handle objects and multiple inheritance;
> >this is because MI relies on the fact that an object can contain another
> >object, but of course you cannot store one relocatable block inside
> >another. For the same reason, it's obviously impossible to use a
> >HandleObject itself (not just a pointer to one) as a member of another
> >object.
> >
> >CFront, Symantec C++ and CodeWarrior all support HandleObject. And in
> >THINK C (which isn't really C++) all objects are allocated in handles.
> >
>
> Really?! Where is this class found in the CodeWarrior directories?
>
> Jim
>
> --
> J.Rodden, DD/MF & Associates
> Simlab Development Team, Product Architect

There is no class.  Simply derive your classes from it.  It is more like
an instruction to the compiler to use a smaller and faster inherited
vtable format otherwise the MI format will be used.

Mark Anderson
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John A. Dunning)
Date: Thu, 23 Mar 1995 22:00:45 GMT
Organization: Princeton University

In article <[e-mail]>,
>It's actually not quite that: it's impossible to use any kind of object
>as a member of a HandleObject (note that this restriction does not
>apply to pointer to objects, however). Thus both
>
>class TMixedObject : TMixin1, TMixin2 {
>       /* This is a subclass of HandleObject */
>...
>  virtual void DoSomething1(); // inherited from TMixin1
>  virtual void DoSomething2(); // inherited from TMixin2
>}
>
>and
>
>class THandleObject {
>       /* This is a subclass of HandleObject */
>...
>  TSomeOtherObject fObject; // contains DoSomething() method
>};
>
>are evil. In the first case, either DoSomething1 or DoSomething2
>(depending on the implementation) will get a "this" that points to
>the middle of the handle (the case you describe). In the second case,
>DoSomething() will get a "this" that points to the middle of the
>handle as well. If the second case, however, had been declared as:
>
>  TSomeOtherObject *fObject;
>
>that would've worked.

What if you always lock the HandleObject before calling its
methods?  Or, if the HandleObject can lock itself, have it lock
itself at the beginning of each of its methods.  Will that
enable you to use multiple inheritance and have other objects
as members of the HandleObject?

John
--

______________________________________________________________________________
John Dunning                                    [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Chris Tate)
Date: Fri, 24 Mar 1995 17:03:17 GMT
Organization: DCRT, NIH, Bethesda, MD

In article <[e-mail]>, [e-mail] (John A. Dunning) writes:
>
> [ speaking of handle-based objects in C++ ]
>
> What if you always lock the HandleObject before calling its
> methods?  Or, if the HandleObject can lock itself, have it lock
> itself at the beginning of each of its methods.  Will that
> enable you to use multiple inheritance and have other objects
> as members of the HandleObject?

Or:

What if, rather than storing 'this' pointers and passing them as arguments
to methods (which as I understand it is the reason why MI fails for handle-
based objects in existing implementations - whereas you can supply a 'this'
pointer into the 'middle' of a composite object, you can't have a 'this'
handle pointing into the middle of another handle), you instead used a 'this'
handle *and an offset into the block*?  This is equivalent to having a
pointer into the middle of the block, and it's invariant over movement of
the block in memory.

Obviously, comparison of 'this' pointers and related issues would need to
be handled specially by the compiler, and stack-based objects might be a
bit of a mess (or might not - I'd have to poke into the details to be sure),
but I don't see why the implementation of 'this' can't change to accomodate
the change in the implementation of a 'pointer' that is implicit in using
handle storage rather than direct pointer storage...

- -----
Christopher Tate
[e-mail]
<http://world.std.com/~ctate/>

+++++++++++++++++++++++++++

>From [e-mail] (Jens Alfke)
Date: Fri, 24 Mar 1995 18:27:46 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Thomas P. Condon) wrote:

> I don't think Jens Alfke understood what was being asked.
>
> The simple answer of why not to do this is that a call to a member
> function always passes an implicit "this" on the stack.

There are two answers to this. HandleObjects don't have this problem at
all, since the 'this' value passed to the method is a _handle_ to the
object, not a pointer. The dereferencing of the handle is done implicitly
whenever 'this' is dereferenced.

Regular C++ objects that live inside a relocatable block do have the
problem you described. But this is just Mac Programming 101: If you pass a
pointer into a relocatable block to a function that can move memory, you
must lock the block down first. The fact that the 'this' pointer is
invisible makes this a wee bit more subtle, but no more than the 'with'
construct in Pascal, which also introduces invisible pointers.


Jens Alfke_________OpenDoc [e-mail]
                                           OpenDoc info: FTP to CILabs.org

         Visit Scenic Flood Control Dam No. 3.

+++++++++++++++++++++++++++

>From Joe Francis <[e-mail]>
Date: 24 Mar 1995 22:19:04 GMT
Organization: Smooth Roo Software

In article <3kv7oo$[e-mail]> ALTURA, [e-mail] writes:
>Is this legal? (by legal, I'm mean ARM compliant and portable):
>
>class foo_c
>{
>
>public:
>   ....
>   virtual void a_virtual_func(void);
>
>};
>
>void foo(void)
>{
>  foo_c*     foo_ptr = new foo_c();
>
>  Handle      foo_h = NewHandle(sizeof(foo_c));
>  if ( foo_h )
>    BlockMove((Ptr)foo_ptr, *foo_h, sizeof(foo_c));
>}
>
>And then later on...
>
>HLock(foo_h);
>foo_c*    foo_ptr = (foo_c*)*foo_h;
>foo_ptr->a_virtual_func();
>

I'm not exactly sure what you mean by portable, since you use Mac-specific
calls in your example.  Do you mean portablility across mac development
environments that support C++?

At any rate, you can do what you do above, but there are some gotcha's.

First off, you have to be careful of side affects of your constructor.
Does it register itself with another class?  If so, the pointer will
be to the object you created, rather than the bitwise copy you made of
it.

Secondly, beware of destroying your copy.  Your compiler may make
assumptions about where objects created with "new" live, and these
assumptions will most likely be all wrong for your hip, handle-dwelling
imposter.  :)

Hope this helps.

- ------------------------------------------------------------------------
Clap... Hop.... say "Kweepa".....
- ------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Thomas P. Condon)
Date: 28 Mar 1995 18:01:27 GMT
Organization: Condon Consulting Services, Inc.

Geez...!  It was just a typo!!!!  Relax guys....

In article <[e-mail]>,
[e-mail] wrote:

> In article <[e-mail]>, Thomas P.
Condon writes:
> >
> > I don't think Jens Alfke understood what was being asked.
> >
> > The simple answer of why not to do this is that a call to a member
> > function always passes an implicit "this" on the stack.  You can get into
> > the situation that
> >
> > 1.) You call myHandleObject->fInnerObject->DoSomething();
> >
> > 2.) The compiler pushes the address to fInnerObject just before it calls
> > TInnerObject::DoSomething(). (Hey! This address points to the middle of a
> > relocatable block!!  DANGER!!!!)
> >
> > 3.) Call TInnerObject::DoSomething(). OOPs!  The routine
> > TInnerObject::DoSomething() is not in memory!  The segment loader goes to
> > work!  Loads the segment! Moves memory! Moves myHandle! Address pushed on
> > the stack is garbage now!!!
> >
> > 4.) KABOOM!
>
> I dont think Thomas P. Condon thought about his answer:-)
> From the syntax, fInnerObject is a pointer (or perhaps a handle) to an
object. So there is no
> problem.
>
> Now if he had written
>         myHandleObject->fInnerObject.DoSomething();
>
> 2),3) and 4) would be valid (unless of course fInnerObject was a
reference to an object)
>
> Mark Williams

+++++++++++++++++++++++++++

>From [e-mail] (Steve Lay)
Date: Wed, 29 Mar 1995 16:37:59 +0100
Organization: DAMTP, Cambridge University


One of the simplest ways to use Mac Handles is to override the new and
delete handlers for a class, for example by subclassing from a class like
CHandleThing described below.

Once the object is unlocked you'll need to be careful about not using the
object pointer in all the usual situations including cross-segment calls.
For this reason the source provides Lock/Unlock functions which exchange a
CHandleThingPtr for a Handle and vice versa.  A better version of these
two routines would use HGetState and HSetState (to allow nested calls) and
would probably be a constructor/destructor pair of a separate object.

There are of course still gotcha's.  Here's one or two:

(1) All notion of type is lost when converting to a Handle (you could fix
this though).

(2) Although you'll realise that you can only Lock and Unlock CHandleThing
objects if they were allocated by their own new operator this is not
enforced.

(3) The code which uses the new operator needs to be able to see
CHandleThing::operator new, which means that sub-classes must inherit from
it (or a sub-class of it) 'publicly'.

(4) As given, the Lock/Unlock may fail in some situations.  To my
knowledge, the return value of CHandleThing::operator new is not required
to be the same as the pointer used to refer to the instance.  For example,
with multiple inheritance the compiler could arrange the classes in memory
in such a way that CHandleThing was not first.  Therefore the method wont
be very portable between compilers.

Although crude I've used this kind of method quite a bit without too much
trouble.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Source from memory, apologies for typos etc....


typedef class CHandleThing {
    public:
    void *operator new (size_t nBytes);
    void operator delete (void *p);
    static Handle UnlockHandleThing (CHandleThingPtr hThing);
    static CHandleThingPtr LockHandleThing (Handle h);
    } *CHandleThingPtr;

void *CHandleThing::operator new (size_t nBytes)
{
Handle h=NewHandle(nBytes);
if (h) {
    MoveHHi(h);
    HLock(h);
    return (void*)*h;
    }
else {
    //  Call error handler if desired...
    return nil;
    }
}


void CHandleThing::operator delete (void *p)
{
if (p) {
    Handle h=RecoverHandle((Ptr)p);
    DisposHandle(h);
    }
}


Handle CHandleThing::UnlockHandleThing (CHandleThingPtr hThing)
{
Handle h=RecoverHandle((Ptr)p);
HUnlock(h);
return h;
}


CHandleThingPtr CHandleThing::LockHandleThing (Handle h)
{
MoveHHi(h);
HLock(h);
return (CHandleThingPtr)*h;
}

--
Steve Lay
[e-mail]
http://www.amtp.cam.ac.uk/icrd

---------------------------

>From Glenn Clingroth <[e-mail]>
Subject: Getting a printer's bit depth
Date: 27 Mar 1995 22:24:20 GMT
Organization: Software Designs Unlimited Inc.

Hi,

How do you go about determining the bit depth of the printer's GrafPort?
Or this may
be the wrong question since I need to know whether the user has selected
color/grayscale
or black & white from the printer's job dialog. Is there a generic way of
doing this? Like
will I be able to tell this same information on StyleWriters,
ImageWriters, and HP printers?

Basically, I want to make printing as simple as possible for the user and
print a halftone
image when that is applicable, but IM-Printing doesn't seem to have the
answers I'm
looking for.

Thanks,

Glenn Clingroth
Software Designs Unlimited

+++++++++++++++++++++++++++

>From [e-mail] (Demos)
Date: Mon, 27 Mar 1995 23:41:19 -0600
Organization: University of Utah

In article <3l7duk$[e-mail]>, Glenn Clingroth
<[e-mail]> wrote:
>
> Glenn Clingroth
> Software Designs Unlimited

Hi Gelnn,
As far as I can tell, printer's bit depth for our LaserWriter is 8, you
can check this by converting THPrPort to CGrafPtr and looking at its
fields. However, i am not 100% sure how it all works, maybe it depends on
the depth of your main device monitor. Hell knows.. :)

Demos

--
Demos <[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (Andreas Wickberg)
Date: Thu, 30 Mar 1995 20:46:01 -0800
Organization: RBI Software Systems

In article <3l7duk$[e-mail]>, Glenn Clingroth
<[e-mail]> wrote:
> Or this may
> be the wrong question since I need to know whether the user has selected
> color/grayscale
> or black & white from the printer's job dialog. Is there a generic way of
> doing this?

Just check the GrafPort you get back from PrOpenDoc. It's going to be an
old style GrafPort (portBits.rowBytes >= 0) if the user chose Black and
White, or a CGrafPort if color/gray scale was selected. As a matter of
fact, that _is_ the semantics of B&W / C&G, you get the old quickdraw
colors in black and white mode.

Andreas

---------------------------

>From [e-mail] ()
Subject: Good Mac software Installer
Date: 18 Mar 1995 15:31:13 GMT
Organization: Internet ProLink

I'm looking for a program that can help me build a simple install
file for the Mac.  I just want to package up some already existing
programs and install them in the correct place.  I bought disk doubler
and it does most of what I need, but I would like to place some files
in already existing folders (like extensions) rather than ask the
user to do it.  Is there something out there that can get me going?

Thanks for your help,
--
Mickey

+++++++++++++++++++++++++++

>From [e-mail] (ALTURA)
Date: 18 Mar 1995 13:07:58 -0500
Organization: America Online, Inc. (1-800-827-6364)

> I just want to package up some already existing
> programs and install them in the correct place.

I like Developer Vise from MindVision.

==========================
Jordan Zimmerman
[e-mail]
http://www.altura.com/jordanz/home.html
Who is John Galt?

+++++++++++++++++++++++++++

>From [e-mail] (Blake)
Date: Sat, 18 Mar 1995 18:26:22 -0500
Organization: Boston University

Smaller Installer is cheap

--
    /\      /\                /\               /\   /\
   /^^\/\  /  \  Blake A. Mitchell        /\ Boston University  /\
  /   /^^\/^^^^\ 617/352-8597     \  /\  /^^\700 Commonwealth Ave.\
 /   /    \/\   \[e-mail] \/^^\/   /Box 3164   \     /^^^^\
/   /      \ \   http://acs2.bu.edu:3795\  / Boston, MA  02215      \

+++++++++++++++++++++++++++

>From [e-mail] (Ed Anson)
Date: Sun, 19 Mar 1995 12:27:22 -0500
Organization: Tulip Software

In article <3keuc1$[e-mail]>, [e-mail] wrote:

> I'm looking for a program that can help me build a simple install
> file for the Mac.  I just want to package up some already existing
> programs and install them in the correct place.  I bought disk doubler
> and it does most of what I need, but I would like to place some files
> in already existing folders (like extensions) rather than ask the
> user to do it.  Is there something out there that can get me going?

Aladdin's StuffIt InstallerMaker does everything you need and more. It is
especially good at placing things into existing folders and can even
determine which folders based on the system version that is running (6 vs
7).

- --------------------
Ed Anson            MediaTree: multimedia outline editor & catalog
Tulip Software
Andover, MA 01810   For details, check out my WWW page:
U.S.A.              <http://www.tiac.net/users/tulip/home.html>

+++++++++++++++++++++++++++

>From [e-mail] (Mike Cohen)
Date: Mon, 20 Mar 1995 00:31:53 GMT
Organization: ISIS International

[e-mail] () writes:

>I'm looking for a program that can help me build a simple install
>file for the Mac.  I just want to package up some already existing
>programs and install them in the correct place.  I bought disk doubler
>and it does most of what I need, but I would like to place some files
>in already existing folders (like extensions) rather than ask the
>user to do it.  Is there something out there that can get me going?

Look at Aladdin's InstallerMaker. You can find a demo at ftp.netcom.com in
/pub/le/leonardr.

--
Mike Cohen - [e-mail]
NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20
Home Page: ftp://ftp.netcom.com/pub/is/isis/home.html
PUSH THE BUTTON, FRANK... OR SOMEONE?

+++++++++++++++++++++++++++

>From [e-mail] (Steve Kiene)
Date: 20 Mar 1995 05:57:09 GMT
Organization: MindVision Software

In article <3keuc1$[e-mail]>, [e-mail] wrote:

> I'm looking for a program that can help me build a simple install
> file for the Mac.  I just want to package up some already existing
> programs and install them in the correct place.  I bought disk doubler
> and it does most of what I need, but I would like to place some files
> in already existing folders (like extensions) rather than ask the
> user to do it.  Is there something out there that can get me going?

Developer VISE Lite from MindVision Software can do this and a lot more.
It's available for a one-time license fee of $295. A demo is available
from ftp.mindvision.com. Developer VISE is the installer of choice at
companies like Claris, Adobe, and Intuit.

Steve Kiene
MindVision Software

+++++++++++++++++++++++++++

>From [e-mail] (Dave Fleck)
Date: Mon, 20 Mar 1995 09:56:08 -0800
Organization: Wacom Technology Corp.

In article <3keuc1$[e-mail]>, [e-mail] wrote:

> I'm looking for a program that can help me build a simple install
> file for the Mac.  I just want to package up some already existing
> programs and install them in the correct place.  I bought disk doubler
> and it does most of what I need, but I would like to place some files
> in already existing folders (like extensions) rather than ask the
> user to do it.  Is there something out there that can get me going?
>
> Thanks for your help,
> --
> Mickey

Smaller Installer is a good value. I really liked Apple's installer - but
licensing went from $50 per year to $2000 per year per language ($14000
for us!) so we dropped it. I understand even Claris doesn't use the Apple
installer. Writing scripts for Apple's installer isn't too bad so I never
found a need to use any of the installer script makers and you still have
to license the Apple installer! That only leaves a couple of installers
left, and many of those have licens fees similar to Apples. There are demo
versions of Smaller Installer available. I believe you can reach them at
[e-mail].

Dave
- ---------------------------------------------------------------
Dave Fleck   email:[e-mail]      phone:[phone]x154
Wacom Technology Corp.                          [e-mail]
501 S.E. Columbia Shores Blvd, #300           [e-mail]
Vancouver, WA 98661                           WWW/FTP:wacom.com
- ----------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Steve Kiene)
Date: 21 Mar 1995 11:50:09 GMT
Organization: MindVision Software

In article <dfleck-2003950956080001@204.119.25.66>, [e-mail] (Dave
Fleck) wrote:

> Smaller Installer is a good value. I really liked Apple's installer - but
> licensing went from $50 per year to $2000 per year per language ($14000
> for us!) so we dropped it. I understand even Claris doesn't use the Apple
> installer. Writing scripts for Apple's installer isn't too bad so I never
> found a need to use any of the installer script makers and you still have
> to license the Apple installer! That only leaves a couple of installers
> left, and many of those have licens fees similar to Apples. There are demo
> versions of Smaller Installer available. I believe you can reach them at
> [e-mail].

You are correct. Claris is phasing out use of the Apple Installer and is
now using Developer VISE. Apple has (again) revised their licensing, and
now you have to pay on a per copy basis. I don't remember the specifics.
Unless you have only one product and you are distributing a really small
number of copies of your software in a one-shot deal, Developer VISE Lite
is probably one of the least expensive installers. It's available for a
one-time license fee of $295. Considering the ease of use of Developer
VISE as compared to Smaller Installer (which costs a minimum of $200),
it's close enough to where you should take a look at all the products and
decide which product works best for your individual needs. You can find
Developer VISE by e-mailing me, or trying ftp.mindivision.com (I'm just
getting our ftp site up and running, so it may be down periodically until
I get it all figured out).

Steve Kiene
MindVision Software

+++++++++++++++++++++++++++

>From [e-mail] (Steve Kiene)
Date: 22 Mar 1995 11:22:02 GMT
Organization: MindVision Software

In article <3kmuc4$[e-mail]>, [e-mail]
(Alex Curylo) wrote:

> Wow, $5 cheaper than DragInstall! What was cut out to make it "Lite"?


Basically it's the same as the old version of the regular Developer VISE
(which has a lot more functionality than DragInstall). Here's the text I
pulled from the programming notes:

Developer VISE Lite
Missing Features List

1. No uncompressed files on install diskettes
   Files can not be stored by Developer VISE as Finder accessible on floppy

2. No Billboards

3. Only 32 packages

4. Translator Applications can not be created
   Translator Applications provide a way to easily translate the data
you9ve entered in your archive to another language.

5. No Dynamic Localization Features
   Simplifies the archive creation process for different languages via
Import-update feature.

6. No Archive Reports

7. No Advanced Settings
   Advanced Settings are accessed via the Preferences window of the
regular version of Developer VISE. The following list describes each
Advanced Setting option.

a. View by Generic Icon in Archive Window
When selected, displays generic icons for files and folders in the Archive
window, the Add window, and the Update Archive window. When not selected,
the icons for each item that appear on the Desktop are displayed.

b. Show Easy Install Package in Custom Install
When selected, Easy Install appears as a selectable item in the Custom
Install window.

c.  Don9t Recompress option.
When selected, additional compression is not performed when creating an
installer. This option can dramatically speed up building time, and will
make the installer slightly larger.

d. No Restart Warnings in the Installer
When selected, the restart warning dialog appearing prior to installation
is removed (under scenarios causing a restart warning dialog box to
occur). The restart suggestion/option dialogs are still provided after the
installation is completed.

e. Maximize Space on Diskette
Disk space is maximized when writing the installer segment/s to floppy.
This results in approximately 14K of extra space available per disk. It
also reduces the amount of free space left on disk.

f. Show Installer Window in background during Install
The In Progress install dialog is drawn on top of the Easy
Install/Customized window.

g. Display Package Names in Progress Dialog
Option shows the package name instead of the file name during the
installation process.

h. Don9t Display Read Me during Installer Launch
The Read Me will accessible only via a Read Me
Install/Custom Install windows.

i. Check Gestalts on Custom Install
Forces the installer to honor Gestalt settings (made from Get Info.
section) for items installed via Custom Install. The Custom Install
previously ignored file level Gestalt settings.

j. Allow Duplicate Resources
Allows you to have resources with the same id as the installer (used to
replace the Developer VISE installer icon with your own custom icon).

k. Easy Install Show Sizes
Shows the disk space available and disk space needed in the Easy Install
window - see frequently asked questions in manual for more details.

l. Replace Disk Pop-up Menu with Select Folder Button
Two buttons (Select Folder & Switch Disk) appear in the Easy
Install/Custom Install windows . The installer normally reveals a location
pop-up menu & a Switch Disk button (provided pop-up menu items are: Select
Folder

m. Ask User Once on Fat Binary Installs
Allows for easy creation of packages such as 3Program X = PowerPC2 &
3Program X - 68K2. You simply assign the same files to both packages, but
change the Install Fat Binary options for each.

n. Force Creation of Moved Items Folder

o. Display Billboards by Package, not by Disk
Allows the billboard pict file shown above the installer application9s in
progress bar to be drawn according to the billboard/s assigned to
package/s.

p. Display Billboards in Separate Window
When selected, billboards will be displayed above the progress dialog, not
on top of it. Please note that the size of the screen is not checked, so
make sure that your billboard will fit on all screen sizes if selecting
this option.

q. Show Remove in Installer
This feature requires you to add your own external code for implementation

r. Put Log File on Root of Volume


Steve Kiene
MindVision Software

+++++++++++++++++++++++++++

>From [e-mail] (Dennis Ryan)
Date: Thu, 23 Mar 1995 23:10:29 -0500
Organization: MacTemps, Inc.

In article <[e-mail]>,
[e-mail] (Steve Kiene) wrote:

> In article <3keuc1$[e-mail]>, [e-mail] wrote:
>
> I'm looking for a program that can help me build a simple install
> file for the Mac.  I just want to package up some already existing
> programs and install them in the correct place.  I bought disk doubler
> and it does most of what I need, but I would like to place some files
> in already existing folders (like extensions) rather than ask the
> user to do it.  Is there something out there that can get me going?


try alladin's insstallermaker. i dont know what the licencing fees are
though. but it does all that you are asking

+++++++++++++++++++++++++++

>From [e-mail] (Ed Anson)
Date: Sat, 25 Mar 1995 20:20:07 -0500
Organization: Tulip Software

In article <[e-mail]>, [e-mail]
(Dennis Ryan) wrote:

> In article <[e-mail]>,
> [e-mail] (Steve Kiene) wrote:
>
> > In article <3keuc1$[e-mail]>, [e-mail] wrote:
> >
> > I'm looking for a program that can help me build a simple install
> > file for the Mac.  I just want to package up some already existing
> > programs and install them in the correct place.  I bought disk doubler
> > and it does most of what I need, but I would like to place some files
> > in already existing folders (like extensions) rather than ask the
> > user to do it.  Is there something out there that can get me going?
>
>
> try alladin's insstallermaker. i dont know what the licencing fees are
> though. but it does all that you are asking

To get details on licensing, call Janet Viets at Aladdin (408-761-6200).
Last I checked, you can license the installer for about $250 per year.
That's what I'm paying, anyway. I find it well worth the price.

- --------------------
Ed Anson            MediaTree: multimedia outline editor & catalog
Tulip Software
Andover, MA 01810   For details, check out my WWW page:
U.S.A.              <http://www.tiac.net/users/tulip/home.html>

+++++++++++++++++++++++++++

>From [e-mail] (Greg Galanos)
Date: Sun, 26 Mar 95 12:17:19 GMT
Organization: Metrowerks Inc.

In Article <[e-mail]>, [e-mail] (Ed
Anson) wrote:

>To get details on licensing, call Janet Viets at Aladdin (408-761-6200).
>Last I checked, you can license the installer for about $250 per year.
>That's what I'm paying, anyway. I find it well worth the price.

Aladdin's InstallerMaker is used in all Metrowerks CodeWarrior releases. We
build archives that are larger than 100 megabytes using IM. We broke it a
couple of times when we were doing DR1 (back in January 1994) but
considering the size of our archives and the industrial beating it took, it
has come out extremely well. Aladdin have fixed all of our outstanding
problems and the CW5 Installer of CodeWarrior was actually a pleasure to build.

-- Greg Galanos, president & CEO, metrowerks inc.

+++++++++++++++++++++++++++

>From Simon Fraser <[e-mail]>
Date: 30 Mar 1995 16:17:09 GMT
Organization: Imperial College, London, UK

> In Article <[e-mail]>, [e-mail] (Ed
> Anson) wrote:
>
> >To get details on licensing, call Janet Viets at Aladdin (408-761-6200).
> >Last I checked, you can license the installer for about $250 per year.
> >That's what I'm paying, anyway. I find it well worth the price.

Does anyone know Aladdin's policy on share- and freeware authors
using InstallerMaker? Do they charge for that?

Simon Fraser
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Steve Kiene)
Date: 31 Mar 1995 01:52:41 GMT
Organization: MindVision Software

In article <3leli5$[e-mail]>, Simon Fraser <[e-mail]>
wrote:

> Does anyone know Aladdin's policy on share- and freeware authors
> using InstallerMaker? Do they charge for that?

Developer VISE from MindVision Software is free to shareware and freeware
authors. Just ask for a copy.

- ----------------------------------------------------------------------
Steve Kiene                              Internet: [e-mail]
MindVision Software                                      AOL: MindVision
840 South 30th Street, Suite C                     AppleLink: MindVision
P.O. Box 81886                                    CompuServe: 70253,1437
Lincoln, NE 68510                                    Fax: [phone]

           ftp://ftp.mindvision.com for demos and information.
---------------------------

>From [e-mail] (David Plumpton)
Subject: InitZone strangeness
Date: Thu, 23 Mar 1995 10:21:35 +1000
Organization: BNR Australia

Here's the situation:
I've created and locked a Handle in multifinder memory with TempNewHandle().
Later on I make a Zone in it with InitZone(), and it works fine.
Further on again, I want to throw away all the previous stuff and start again,
so I make another call to InitZone(), with *identical* parameter values to
the first call, and everything freezes up.

The handle is still allocated and locked.
Before the InitZone() call both times the current zone is the application zone.
Stepping into the call with Metrowerks debugger in assembler there are a few
loads and then a bl *+someBigNumber, and this is where it dies.

I'm using a PowerMac 6100/60 AV, System 7.5, Codewarrior 5.5, Modern Memory
Manager on.

Any ideas out there?

p.s. Did you know it's possible to create a zone with the two pointers
backwards. I did this by accident once, and InitZone() likes it, MemError()
is happy, and MaxBlock() returns a negative number. Freaky.

--
David J. Plumpton           Nobody wants my opinions.
[e-mail]              PGP Public Key available on request.

+++++++++++++++++++++++++++

>From [e-mail] ([e-mail])
Date: 23 Mar 1995 01:37:22 GMT
Organization: Dartmouth College, Hanover, NH

In article <plumpto-2303951021360001@47.181.192.81>
[e-mail] (David Plumpton) writes:
> I've created and locked a Handle in multifinder memory with TempNewHandle().
> Later on I make a Zone in it with InitZone(), and it works fine.
> Further on again, I want to throw away all the previous stuff and start again,
> so I make another call to InitZone(), with *identical* parameter values to
> the first call, and everything freezes up.
>
> The handle is still allocated and locked.
> Before the InitZone() call both times the current zone is the application zone.
> Stepping into the call with Metrowerks debugger in assembler there are a few
> loads and then a bl *+someBigNumber, and this is where it dies.
>
> I'm using a PowerMac 6100/60 AV, System 7.5, Codewarrior 5.5, Modern Memory
> Manager on.
>
> Any ideas out there?
>

There is a new routine introduced with the Modern Memory Manager called
DisposeZone.  It is only available when the modern memory manager is
active.  So, for example, if you turn MMM off on your Power Mac, your
problem will go away.  Likewise, if you run your program on a 68K Mac
(which does not have MMM), you will not see the problem.  I think the
MMM keeps a list of zones, and so you need to tell it when a zone is
going away.  In other words, you need to call DisposeZone before
re-initing over that old zone.

Here's some code that I use that tests if DisposeZone is present and
then calls it if necessary:


#if USES68KINLINES
#pragma parameter __A0 DisposeZone(__D0)
#endif
extern pascal OSErr DisposeZone(THz zone)
 TWOWORDINLINE(0x701D, 0xA0A4);

void
dispose_zone (THz zone)
{
    if (zone->heapType & kNewStyleHeap)
        DisposeZone(zone);
}

DisposeZone is actually a selected routine (D0=0x1D) of _HeapDispatch
(0xA0A4).  You can check if a particular heap is "modern" by testing
bit 1 of heapType (which used to be maxNRel).  If the heap is modern,
the trap is implemented.  If the heap is not modern, then there is no
need to call DisposeZone.

Note that kNewStyleHeap and heapType (nee maxNRel) are both defined in
memory.h (universal headers).  DisposeZone was omitted for some reason.

> p.s. Did you know it's possible to create a zone with the two pointers
> backwards. I did this by accident once, and InitZone() likes it, MemError()
> is happy, and MaxBlock() returns a negative number. Freaky.

"Hey doc, it hurts when I do this."  ;-)  ;-)  ;-)

Good luck,

Mark.

- --------------------------------------------------------------------
"On the Internet, nobody knows you're a dog."   Ice Peak Form Mice Elf
                    -- cartoon in New Yorker

+++++++++++++++++++++++++++

>From [e-mail] (Grobbins)
Date: Tue, 28 Mar 1995 22:06:30 -0700
Organization: Skunkworks

In article <3kqjci$[e-mail]>,
[e-mail] ([e-mail]) wrote:
>There is a new routine introduced with the Modern Memory Manager called
>DisposeZone.  It is only available when the modern memory manager is
>active.

Since Apple hasn't documented this, it's probably best to avoid making the
call.  The modern memory manager will dispose of a zone contained in a
Handle or Pointer when the block is disposed with DisposeHandle or
DisposePtr.  So if you create a heap zone, put it in a memory manager
block (in a temp handle is fine) and dispose of the block when you're done
with the heap. Don't put heap zones on the stack or dispose of them by
simply overwriting them.

Grobbins                           [e-mail]

---------------------------

>From [e-mail] (KENT SOERENSEN)
Subject: Postponing AE reply ?
Date: Wed, 22 Mar 95 01:37:00 +0100
Organization: Danish Key Board BBS - Copenhagen Denmark - [phone]


How do I "postpone" replying to an AppleEvent ?

It appears that a reply to an AppleEvent must be completed inside the
function that is called by AEProcessAppleEvent.

I've written a plug-in to extend the scripting ability of an existing
application. When it processes the AppleEvent, the plug-in is called
differently than when it is normally called by the application. Therefore
it doesn't have access to the information it needs to fully process the
event. So I store the parameters in a structure, return from the function,
and look at the parameters in the next normal invocation. So far so good.

However, now I can't reply to the original AppleEvent...

The sender of the event is AppleScript, and I'd really like if someone out
there could give me some advice, on how to return information so that
AppleScript can use it.

Thanks in advance.

Bye,
  Kent


- -
TIMM (1.0e)
Real Programmers never work 9 to 5. If any real programmers are around at
9 am, it's because they were up all night.

+++++++++++++++++++++++++++

>From [e-mail] (Paul M. Hoffman)
Date: Thu, 23 Mar 1995 11:42:42 -0500
Organization: University of Michigan

In article <[e-mail]>, [e-mail] (KENT
SOERENSEN) wrote:

> How do I "postpone" replying to an AppleEvent ?

Ouch!  I always hate to see this question, because I had to get my brain
around this thorny problem once and having done so slipped into a sort of
bruised but blissful forgetfulness.  The short answer is, use
AESuspendTheCurrentEvent to suspend the event and AEResumeTheCurrentEvent
to resume processing.  My understanding of this issue may not be
exhaustive (or even *entirely* correct), so caveat emptor etc., but FWIW
read on for more info.

> It appears that a reply to an AppleEvent must be completed inside the
> function that is called by AEProcessAppleEvent.

Not necessarily -- it depends on what the caller (the process that sent
the Apple Event) expects in the way of a reply.  If it's *waiting* for a
reply (i.e., it called AESend with the kAEWaitReply flag set in the
sendMode parameter) then it will get an errAETimeout (-1712) error if you
suspend handling and don't resume (and finish) it soon enough.  (Come to
think of it, it may get an errAETimeout error regardless.  Read Inside
Mac: Interapplication Communication for holy writ.)

If, however, it expects to receive a reply event, (i.e., it called AESend
with the kAEQueueReply flag set in sendMode), then you can suspend the
event, then later resume it and still return a meaningful reply.

> I've written a plug-in to extend the scripting ability of an existing
> application. When it processes the AppleEvent, the plug-in is called
> differently than when it is normally called by the application. Therefore
> it doesn't have access to the information it needs to fully process the
> event.

Well, if possible I would change this so that there are optional
parameters to the event.  May not be possible, I know, but...  Ideally
everything's factored so that you don't have to get around this kind of
thing.  [Yes, I do believe we live in an ideal universe, but who's ideal
is it? -- not mine!]

> So I store the parameters in a structure, return from the function,
> and look at the parameters in the next normal invocation. So far so good.
>
> However, now I can't reply to the original AppleEvent...
>
> The sender of the event is AppleScript, and I'd really like if someone out
> there could give me some advice, on how to return information so that
> AppleScript can use it.

There may be some specific restrictions imposed on suspending and resuming
events in your case.  The script that sends you the event may require a
"with timeout of n seconds"/"end timeout" block; there are other tricky
things I won't go into here.  Definitely read Inside Mac: Interapplication
Communication carefully -- the relevant pages are (most important) 4-85 to
4-88 and (for AESend) 5-37 to 5-41.  Then try it and if it works, great.

OK, here's my code (adapted from some Dragonsmith code).  It's worked well
so far, but then it's really only been tested with multiple 'odoc' events
from the Finder.  The idea is that you have to keep your own queue of
waiting-to-be-processed Apple Events and check it promptly when you're
(more or less) idle.  This is what my 'odoc' handler does:

   // If we're already processing an Apple event, suspend this event
   if (runState & maskBusy) {
      err = aeQueue->Put (event, reply, handler, refcon);
      if (err == noErr) {
         numAEsPending++;
         err = AESuspendTheCurrentEvent (event);
      }
      return err;
   } else {
      ... actually handle the event and return an error here ...
   }

Then my main event loop does something like this:

   WaitNextEvent (everyEvent, &event, sleepTime, NULL);
   DoEvent (&event);
   if (numAEsPending > 0) {
      err = aeQueue->Get (&event, &reply, &handler, &refcon);
      if (err == noErr && handler != NULL)
         err = AEResumeTheCurrentEvent (&event, &reply, handler, refcon);
      if (--numAEsPending < 0)
        numAEsPending = 0;
   } else
      DoIdle ();

Here, aeQueue is an object of my AppleEventQueue class.
AEResumeTheCurrentEvent results in the Apple Event handler being called
all over again.  This is why it's called *after* handling the event
returned by WNE -- putting it between WNE and DoEvent would be a Very Bad
Thing.  [Of course, if you want to handle events in reverse order, just
use a stack instead of a queue -- neat, huh?!]

[VERY IMPORTANT: When you queue the event -- which my code does with
aeQueue->Put (...) -- you must save a copy of the Apple Event itself,
*not* a pointer to it.  Likewise for its reply event.  My code may *look*
like it's queuing pointers, but it's really queuing the event data pointed
to by the pointers.  (My AppleEventQueue::Put essentially just allocates a
handle, crams everything into it, and sticks it at the end of a queue;
AppleEventQueue::Get sucks everything out of the frontmost item in the
queue, disposes of the storage it occupied, and removes the item from the
queue.)]

> Thanks in advance.

No problem.  I hope this helps.  It's good to refresh my memory on it, anyhow.

Paul.

--
Paul Hoffman            +-----+ E-mail: [e-mail]
Taubman Medical Library | pmh | WWW: http://www.umich.edu/~nkuitse/
University of Michigan  +-----+ "Dragons do not enter into this message"

+++++++++++++++++++++++++++

>From [e-mail] (Jeff Amfahr)
Date: Tue, 28 Mar 1995 21:13:31 GMT
Organization: Pharos Technologies

Take a look at AESuspendEvent and AEResumeEvent. They should do the trick
for you.

--
 "This isn't right.  This isn't even wrong."
                                Wolfgang Pauli

---------------------------

>From [e-mail] (weibel)
Subject: Simple Sound
Date: 29 Mar 1995 02:05:43 GMT
Organization: Colorado Supernet

How does one play a sound resource in a program?  If possible
please show a simple snippet (in C) that will preform this.

Thank You
  David

+++++++++++++++++++++++++++

>From [e-mail] (F. Degott)
Date: 29 Mar 1995 12:49:08 GMT
Organization: LMC-IMAG Grenoble France

In article <3laf9n$[e-mail]>, [e-mail] (weibel) wrote:

> How does one play a sound resource in a program?  If possible
> please show a simple snippet (in C) that will preform this.
>
> Thank You
>   David

Hi David,

this is a sample procedure to play a resource sound (in pascal, sorry...).

 procedure PlaySound;
  const
     SoundResType = 'snd ';{snd res type: 4 caracters, the last is a space}
     SoundResID = 1000;{the sound to play}
  var
     sndHdl: Handle;
     err: integer;
 begin
    sndHdl := GetResource(SoundResType,SoundResID);
    if sndHdl <> nil then
     begin
        err := SndPlay(nil,sndHdl, true);
        ReleaseResource(sndHdl);
     end;
 end;{PlaySound}

Bye.

--
__________________________________________
F.R. Degott  ([e-mail])
Lab. LMC-IMAG - Univ. Joseph Fourier - Grenoble - France

---------------------------

>From [e-mail] (Ville Kdrkkdinen)
Subject: TETextBox - How many lines ?
Date: Mon, 27 Mar 1995 11:08:45 +0100
Organization: FOA 11


Hello world !

Today I use the method below to output text to the screen.

void AReportPane::DrawComment(Point start,Handle textHandle) {
Rect rect;
long length;

   rect.left = start.h;
   rect.top = start.v;
   rect.bottom = 32000;
   rect.right = pageRect.right - 20;

   length = GetHandleSize(textHandle);

   if (length > 0) {
      TETextBox(*textHandle,length,&rect,teFlushLeft);
   } else {
      MoveTo(start.h,start.v + 12);
      DrawString("\pNo comment");
   }
}


Is there any way to get at the actual number of lines drawn (or height in
pixels) by TETextBox without getting to much involved in organizing the
text
in style runs and such.

The height info would be needed for further formatting purposes.

+++++++++++++++++++++++++++

>From [e-mail] (MuffinHead)
Date: 27 Mar 1995 10:53:12 GMT
Organization: Armpit Studios VII

In article <[e-mail]>,
[e-mail] (Ville Kdrkkdinen) wrote:

>void AReportPane::DrawComment(Point start,Handle textHandle) {
>Rect rect;
>long length;
[...]
>
>   length = GetHandleSize(textHandle);
>
>   if (length > 0) {
>      TETextBox(*textHandle,length,&rect,teFlushLeft);
>   } else {
>      MoveTo(start.h,start.v + 12);
>      DrawString("\pNo comment");
>   }
>}
>
>Is there any way to get at the actual number of lines drawn (or height in
>pixels) by TETextBox without getting to much involved in organizing the
>text
>in style runs and such.
>
>The height info would be needed for further formatting purposes.

   Since this is obviously non-styled text, you won't have to worry about
style runs. I imagine the easiest way to do this would be to create a
TEHandle with the rect used above, insert the text into that, then just
look at (**te).nLines. Multiply that by (ascent + descent + leading)
obtained from GetFontInfo for the current port (if it's the same as your
TE's.

Muff                                               Armpit Studios VII
Drummer, Mac geek                                       Iowa City, IA
_____________________________________________________________________
[Dorky quote under construction.]

+++++++++++++++++++++++++++

>From [e-mail] (F. Degott)
Date: 30 Mar 1995 11:38:33 GMT
Organization: LMC-IMAG Grenoble France

In article <[e-mail]>,
[e-mail] (MuffinHead) wrote:

> In article <[e-mail]>,
>    Since this is obviously non-styled text, you won't have to worry about
> style runs. I imagine the easiest way to do this would be to create a
> TEHandle with the rect used above, insert the text into that, then just
> look at (**te).nLines. Multiply that by (ascent + descent + leading)
> obtained from GetFontInfo for the current port (if it's the same as your
> TE's.
>

Yes, but don't forget to call TECalText before.
Bye.
__________________________________________
F.R. Degott  ([e-mail])
Lab. LMC-IMAG - Univ. Joseph Fourier - Grenoble - France

---------------------------

>From [e-mail] (The Bard)
Subject: [Q] Going modal-less?
Date: Thu, 30 Mar 1995 15:23:12 -0600
Organization: Bard 'O Matic Software

Ok this is the deal:

I have a list in a window that has a bunch of item in it. The user scroll
through the list, ect and double click on an item. At this point a modal
dialog pops up and the user can edit 15 or so fields.

Now, modals are ugly, evil things and I wast to get away fromn them. So,
what I was thinking was enarging the original window and having the fields
next to the scrolling list. That way, when the user clicks on an item in
the list, the fields to the right of the list automaticly fill in and can
be edited.

Now, the problem:

I'm kind of fuzzy on how to do this. I know creating 15 TEHandles can't be
correct. so that leaves creating one TEHandle and mapping it to 1 of 15
different places on the screen on the fly depending on where the cursor is
at the time. Still, this seems kind of ugly, and I'm thinking there has
got to be a better way. So, is there a better way? :)

Wayde

+++++++++++++++++++++++++++

>From [e-mail] (Demos)
Date: Thu, 30 Mar 1995 03:31:05 -0600
Organization: University of Utah

In article <[e-mail]>,
[e-mail] (The Bard) wrote:
zzy on how to do this. I know creating 15 TEHandles can't be
> correct. so that leaves creating one TEHandle and mapping it to 1 of 15
> different places on the screen on the fly depending on where the cursor is
> at the time. Still, this seems kind of ugly, and I'm thinking there has
> got to be a better way. So, is there a better way? :)
>
> Wayde

hey buddy,
why don't you just use C++? Like.. PowerPlant? It would be so *much*
easier to do!

_____________________________________________________________________
Demos <[e-mail]> | IRC:#macdev | anonymous FTP: 128.110.196.231

+++++++++++++++++++++++++++

>From [e-mail] (The Bard)
Date: Thu, 30 Mar 1995 17:23:30 -0600
Organization: Bard 'O Matic Software

In article <[e-mail]>, [e-mail]
(Demos) wrote:

> hey buddy,
> why don't you just use C++? Like.. PowerPlant? It would be so *much*
> easier to do!

Welp, I really prefer C to C++ (yea I know, don't start...) Plus I'm a
control freak and I wanna know exactly whats going on most of the time...

Wayde

+++++++++++++++++++++++++++

>From [e-mail] (Ivan M CaveroBelaunde)
Date: Fri, 31 Mar 1995 01:38:23 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (The Bard) writes:
>I have a list in a window that has a bunch of item in it. The user scroll
>through the list, ect and double click on an item. At this point a modal
>dialog pops up and the user can edit 15 or so fields.

>Now, modals are ugly, evil things and I wast to get away fromn them. So,
>what I was thinking was enarging the original window and having the fields
>next to the scrolling list. That way, when the user clicks on an item in
>the list, the fields to the right of the list automaticly fill in and can
>be edited.

>Now, the problem:

>I'm kind of fuzzy on how to do this. I know creating 15 TEHandles can't be
>correct. so that leaves creating one TEHandle and mapping it to 1 of 15
>different places on the screen on the fly depending on where the cursor is
>at the time. Still, this seems kind of ugly, and I'm thinking there has
>got to be a better way. So, is there a better way? :)

I've used that approach before. It's pretty easy and clean if you use
abstraction properly (note that this is pseudocode):

//      Begin SharedTEHandle.h

typedef struct SharedTE SharedTE, **SharedTEHandle;

typedef (*RelinquishSharedTEProcPtr)(SharedTEHandle teHandle, long ownerRef);

SharedTEHandle InitSharedTEHandle();

// Claim and relinquish ownership

GetSharedTEHandle(SharedTEHandle sharedTE, long ownerRef,
 StringPtr theText, RelinquishSharedTEProcPtr ownerProc, Rect *teRect);

RelinquishSharedTEHandle(SharedTEHandle sharedTE, owner wasMe);

// Get and Set Text Routines

SetSharedTEHandleText(SharedTEHandle sharedTE, StringPtr theText,
 long me);

GetSharedTEHandleText(SharedTEHandle sharedTE, StringPtr theText,
 long me);



//      Begin SharedTEHandle.c

#include "SharedTEHandle.h"

struct SharedTE {
 TEHandle *theHandle;
 long      ownerRef;
 RelinquishSharedTEProcPtr ownerProc;
};

SharedTEHandle InitSharedTEHandle()
{
        //      allocte the TEHandle and te SharedTEHandle struct.
        //      Set the owner to zero, the text inside the teHandle
        //      to empty
}

GetSharedTEHandle(SharedTEHandle sharedTE, long ownerRef,
 StringPtr theText, RelinquishSharedTEProcPtr ownerProc, Rect *teRect)
{
        //      Call RelinquishSharedTEHandle with the owner parameter
        //      set properly (owner field). Zero out owner and ownerProc,
        //      stick theText into the TEHandle, set the
        //      teRect appropriately, and stuff ownerRef and ownerProc
        //      into the struct
}

RelinquishSharedTEHandle(SharedTEHandle sharedTE, owner wasMe)
{
        //      If wasMe is not the owner, bail; otherwise,
        //      if owner and ownerProc are nonzero call the ownerProc,
        //      zero out owner and ownerProc and return
}

SetSharedTEHandleText(SharedTEHandle sharedTE, StringPtr theText,
 long me)
{
        //      If me is the owner, stick theText into the TEHandle
}

GetSharedTEHandleText(SharedTEHandle sharedTE, StringPtr theText,
 long me)
{
        //      If me is the owner, get the text from the TEHandle
        //      and return it in theText
}

//      End of pseudocode

Use of the library is left as an exercise for the reader. It'd also
be much nicer in C++, but it does the job as is.

-Ivan
- --
Ivan Cavero Belaunde ([e-mail], [e-mail])
Avid VideoShop Lead
Avid Technology, Inc.

---------------------------

End of C.S.M.P. Digest
**********************